Developer Documentation

QuickTime 4 API Documentation

QuickTime For Windows Programmers

| Previous | Chapter Contents | Chapter Top | Roadmap | Next |

Resources

Mac OS resources are items of structured data that reside in files and can be read in on demand to help determine a program's behavior. Although Windows has the concept of resources as well, they're far less central to the system's software architecture than they are on the Mac OS platform.

Every Mac OS file consists of two separate forks, stored independently but logically joined under a single file name. The data fork consists of a single stream of data bytes intended to be read sequentially, and corresponds to what's generally considered a file on most other platforms. The resource fork, by contrast, contains a collection of individual resources that are accessed via a four-character resource type and an integer resource ID. For example, an icon to be displayed on the screen might be identified by resource type 'ICON' and resource ID 1; the contents of a menu by type 'MENU' , ID 128; the layout of a dialog box by type 'DLOG' , ID 1000; and so forth.

Four-character codes like the ones that represent resource types are used on the Mac OS platform for a wide variety of other purposes as well. For example, every file is stamped with a four-character file type and a four-character creator signature identifying the application program to which the file belongs; these play an analogous role on the Mac OS platform to the three-character file-name extension in the DOS/Windows file system.

QuickTime uses four-character codes to identify such things as track types, media types, and component types. Internally, such codes are simply 32-bit long integers; at the source-language level, they are typically represented by a string of four characters enclosed in single quotation marks, such as 'abcd' .

Because DOS/Windows files don't have a counterpart to the Macintosh resource fork, other mechanisms have to be adopted to accommodate resource information. For example, although QuickTime movie files use both forks on the Mac OS platform, those on Windows have only the equivalent of the data fork. One approach is to store only the contents of the data fork from the Mac OS movie file into the corresponding Windows movie file (extension .mov ), while storing the resource fork into a companion file with extension .qtr ("QuickTime resources"). If a needed resource cannot be found in the .mov file, the QTML resource-handling routines will automatically look for a matching .qtr file and will attempt to locate the resource there. The drawback to this approach is that the user, when moving or copying a movie file from one place to another, must remember to move the matching resource file along with it. This is a nuisance to the user and is likely to lead to dissatisfaction with your application.

Fortunately, QuickTime supports another solution to the cross-platform resource problem. The QuickTime function FlattenMovie allows you to create a single-fork movie file with an empty resource fork and all of the resource data stored in the data fork instead. The resulting file can then be transported to Windows (or other platforms) without losing any of the movie's data. This is generally a better solution for cross-platform compatibility, since it requires the user to move one file instead of two.

In porting existing QuickTime applications from the Mac OS platform to Windows, the problem also arises of how to transport resources belonging to the application program itself. On the Mac OS platform, such resources normally reside in the resource fork of the application ( 'APPL' ) file. A utility named RezWack, provided as part of the QuickTime 3 Software Development Kit for Windows, incorporates these resources from the resource fork of the Mac OS version into the executable ( .exe ) file of the Windows version. The QTML resource-management routines will correctly locate and read in the resources from the application's .exe file.


© 1998 Apple Computer, Inc.

| Previous | Chapter Contents | Chapter Top | Roadmap | Next |